Modern database systems store large amounts of electronic data. This data may be received at regular intervals or substantially continuously. The stored data may be accessed for reporting and/or analytical purposes. The sheer amount of data often creates a significant burden on storage and processing systems.
Many techniques have been developed to alleviate this burden. In one example, stored data is apportioned among separate physical memory areas, or partitions. A partition may store related data, such that processing requires interaction with a single or a small number of partitions. This arrangement may also provide simple deletion of old data, by dropping a partition which stores the old data.
A developer or system administrator defines a location, a partition size and a partition content of a database partition, ideally prior to using the database partition. The size of the partition content (i.e., the size of data records which are to be stored in the database partition) is often unknown, so the developer will typically either define too large a partition size (resulting in unused storage capacity) or too small a partition size (resulting in error and/or ad-hoc increases in the partition size). These inefficiencies may be addressed by re-partitioning based on actual received data records, but re-partitioning results in a high system load and requires exclusive locks to move the data among the partitions.